r? @BoxyUwU

rustbot has assigned @BoxyUwU.
They will have a look at your PR within the next two weeks and either review your PR or reassign to another reviewer.

Use r? to explicitly pick a reviewer

Wasn’t this helping to remove some use cases for build scripts?

The part that was supposed to help with build script was the cfg(target = "...") part of the RFC, but that part was already withdrawn.

IIRC the target abi was only matchable in build scripts, is that still the case today (with and without this PR)? To be able to lower the need for build scripts in the ecosystem we need cfgs to be at least isomorphic…

This PR doesn't change anything for matching on specific target cfgs components. This PR only removes the shorthand cfg(target(os = "linux")) -> cfg(target_os = "linux").

As for the target abi, the target_abi cfg was stabilized in 1.78.

Good. Thank you for the clarifications.

I think we should close this for now. If another RFC comes along that obviates the need for this feature, we can remove it then.

@rfcbot reviewed

It's not obvious to me that

cfg(target(os = "linux", arch = "arm")

is better enough than

cfg(all(target_os = "linux", target_arch = "arm"))

to be worth having two ways.

So I think I'm weakly inclined to agree with Urgau here and just remove the short-hand.

Pondering: would cfg_match! being stabilized (#115585 (comment)) affect this at all?

Conceivably, we could have rustfmt normalize to the nicer form (after maybe considering your MSRV). In the long term, that would make it feel less like we had two ways to do it. Anyway, that's not a proposal; it's just to say we have options.

I don't see how the "two ways to do it" feeling will go away entirely. For example, here's two #[cfg(...)]s I've written or read in the past months where normalizing to use target(...) is either not applicable at all or IMHO makes it worse if you try to rearrange the boolean connectives to make it applicable:

• all(any(target_arch="x86", target_arch="x86_64"), feature = "std")
• all(any(target_arch="aarch64", target_arch="arm64ec"), target_endian="little")

It's longer, but in certain contexts, I could imagine preferring

#[cfg(any(
  target(arch="aarch64", endian="little"),
  target(arch="arm64ec", endian="little"),
))]

to the more compressed form. I wonder to what degree preferring the more compressed form might just be an artifact of

#[cfg(any(
  all(target_arch="aarch64", target_endian="little"),
  all(target_arch="arm64ec", target_endian="little"),
))]

being even more expanded.

Turning back to the compressed form, and to whether we could ever normalize to the new way, these seem about the same to me:

#[cfg(all(any(target_arch="aarch64", target_arch="arm64ec"), target_endian="little"))]
#[cfg(all(any(target(arch="aarch64"), target(arch="arm64ec")), target(endian="little")))]

The reason why I think replicating the target_endian part makes that expression worse is because it doesn't match the way I think about why that condition exists. The any(target_arch="aarch64", target_arch="arm64ec") is for having access to 64-bit NEON intrinsics in principle, it's an atomic unit matching the documented requirement for core::arch::aarch64 existing. The endian part is solely about rust-lang/stdarch#1484, which isn't specifically about "little endian AArch64" and "little endian ARM64EC" but about core::arch::aarch64 in general.

I originally had a tangent about target(foo=..) for target_foo=.. but ended up deleting it because I didn't see anyone specifically advocate for it. If that is on the table, my gut reaction is that it seems like a lot of churn for no benefit (if anything, it's very slightly worse to type and read because you have to match parentheses). That is, I don't see any reason to do it unless one is already firmly committed to the target(..) syntax and wants to patch up the downside of having two ways to spell the same conditions.

Yes, it depends what you're trying to emphasize, in context.

FWIW, I think rust-lang/rfcs#3796 is a better solution for compactly expressing things like this.

(No objection to either stabilizing or closing. Mild preference for closing.)

EDIT(workingjubilee): in meeting "preference for closing" was clarified as "preference for ripping out"... the "double-negative" of this FCP got confusing

☔ The latest upstream changes (presumably #143460) made this pull request unmergeable. Please resolve the merge conflicts.

By way of attempting to unblock this (in either direction):

This shorthand seems like it entirely rests on the duplication of the various target_ prefixes. To what extent would this be entirely obviated by, for instance, providing os as an alias for target_os, arch as an alias for target_arch, and similar?

We don't necessarily want that for every target variable, for instance env might be confusing, but at least many of the common ones seem like they'd be fine.

In the context of cfg, target_ seems redundant. In theory, we could have variables for the build host, but we don't and it's not obvious that we'd want to.

I don't really see aliases as an alternative for this. It's appealing, I think, to have target written explicitly, and what was nice about cfg(target(arch = "..", os = "..")) is that it preserved this hierarchy while making it a bit more concise and maybe sparking a bit more joy.

That said, the cfg_version discussions have shifted my feelings slightly about adding new configuration predicates. Maybe it's weariness. Maybe it's uncertainty about whether it's worth the page in the Reference to document this little nicety. Anyway, I've come around to being every-so-slightly in favor of pulling it out, in its current form. So:

@rfcbot cancel

@traviscross proposal cancelled.

@rfcbot fcp merge

Team member @traviscross has proposed to merge this. The next step is review by the rest of the tagged team members:

• @joshtriplett
• @nikomatsakis
• @scottmcm
• @tmandry
• @traviscross

No concerns currently listed.

Once a majority of reviewers approve (and at most 2 approvals are outstanding), this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

cc @rust-lang/lang-advisors: FCP proposed for lang, please feel free to register concerns.
See this document for info about what commands tagged team members can give me.